It has long been known to use in data-bases tables that are continuously updated or changed in different ways by different transactions. Such changes are called schema changes. There are also transactions that do not result in a schema change.
By schema is meant the prevailing configuration of tables in the data-base. This configuration may include
the format of tables, i.e. table names, properties, fragmentation and different safety aspects; PA1 the attributes allocated to different table columns, i.e. the type of information the attributes can store; PA1 what keys exist, i.e. how external references are translated to internal references; PA1 what foreign keys are found, i.e. the nature of different links between tables; PA1 what different indexes are found, i.e. what search paths are found to different attributes in a table; PA1 what triggers are coupled to a table, i.e. the special events that start, "trigger", another event, such that the change of data in a table triggers updating of another table in accordance with the change and in accordance with an existing key, possibly a foreign key.
The term schema, however, implies much more than what has been described above, but these meanings of the term, however, are some of the meanings that will be used in conjunction with the following description of the present invention.
In a distributed data-base, different tables are divided into a plurality of different fragments. Such a fragment includes, in turn, a number of copies or replicas of the same part of the table. Different fragments and their respective copies are physically found in different nodes in a system of mutually co-operating computers. The reliability of the system is improved by spreading the various copies belonging to a fragment, since this makes information available somewhere in the system, even though one or more system nodes should crash.
Schema changes within distributed data-bases can thus be relatively complicated, since all copies of a fragment affected by a schema change must be updated according to the change.
Schema changes in a data-base are based on different conditions and often include a number of different participants, causing a schema change to generate changes in different tables and/or, when the data-base is a distributed data-base, in different parts, fragments, of one or more tables in the data-base.
A schema change results in a change in the conditions for all users of the data-base and also the conditions for transactions between these users. Mention can also be made of different schema versions where a schema change results in the replacement of a first schema version with a second schema version.
Schema changes can be divided into different categories. Firstly, schema changes can be "simple" or "complicated", and, secondly, can be "soft" or "hard" changes. These change characteristics are partially independent of each other. Complicated schema changes can either be hard or soft, whereas simple schema changes are always soft.
Simple schema changes solely change the schema and not data within affected tables. Complicated schema changes alter both the schema and the data in one or more tables.
Put simply, the first and second schema versions are mutually compatible in a soft schema change. The second schema version is not compatible with the first schema version, however, in the case of a hard schema change.
By compatibility is meant that transactions according to the first schema version are able to update data in tables according to the second schema version, via mapping or a function, and transactions according to the second schema version can update data in tables according to the first schema version, via mapping or a function.
Thus, soft schema changes where preceding and following schema versions are compatible with one another enable transactions to be carried out simultaneously in accordance with both schema versions.
In the case of hard schema changes, the mapping or the function whereby tables in the second schema version can be updated with data from the first schema version, or vice versa, is not invertible, in other words tables in the first schema version cannot be updated with data from the second schema version, or vice versa.
Thus, all commenced transactions that affect units which, in turn, are affected by a hard schema change must be terminated in accordance with the first schema version before a schema change can be commenced. Only when the schema change has been completed can transactions begin in accordance with the second schema version.
Thus, no transactions according to the second schema change can be commenced during the time taken to terminate ongoing transactions and to carry out the schema change concerned. These transactions must wait for the termination of transactions according to the first schema version and for the schema change to be carried out, resulting in a considerable time loss.
Complicated schema changes require a change in several phases, since these changes affect both data and schema per se. Complicated schema changes include a number of mutually sequential schema changes and transactions.
The following publications describe known techniques concerning methods of performing schema changes, and also disclose various problems and encountered in this field.
"Axiomatization of Dynamic Scheme Evolution in Objectbases", 11th International Conference on Data Engineering, Mar. 1995, pp. 156-164, by R. J. Peters and M. T. Ozsu.
"Beyond Schema Evolution to Data-base Reorganization", Proc., ACM OOOPSLA/ECOOP '90, pp. 67-76, Ottawa, Canada, Oct. 1990, by B. S. Lerner and A. N. Habermann.
"Type Evolution Support for Complex Type Changes", Technical Report UM-CS-94-71, University of Massachusetts; Amherst, Oct. 31, 1994, by B. S. Lerner.
"Schema Evolution and Integration, Distributed and Parallel Data-bases", Vol. 2, Jan. 1, 1994, ISSN 0926-8782, by S. M. Clemen.
It should also be mentioned that the use of so-called SAGA transactions in conjunction with data-bases is known in this field. In this regard, a first transaction can be performed with the possibility of utilising a following second transaction which will undo the changes caused by the first transaction.
With regard to the earlier standpoint of techniques in this particular field, it can be mentioned that, when changing software within a computer system, it is known to install the new software in parallel with the old software.
Subsequent to this installation, the new software can be evaluated or tested before the old software is removed. Should the test show that the new software does not function satisfactorily, the software can be removed and the old software again taken into use. If the test shows that the new software functions satisfactorily, the new software is taken into use and the old software removed. US-A 5,410,703 gives an example of such a method.